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SYSTEM AND METHOD FOR BUILDING SOURCE CODE FOR 
CONNECTING TO SYSTEMS 

CROSS-REFERENCE TO RELATED APPLICATIONS 

This application is based upon and claims priority to U.S. provisional 
patent application Serial No. 60/314,408, filed on August 23, 2001, and entitled 
SYSTEM AND METHOD FOR BUILDING SOURCE CODE FOR 
CONNECTING TO CORE PROCESSING SYSTEMS, the entire disclosure of 
which is hereby incorporated by reference. 

FTELD QF THE INVENTION 

The present invention relates to a system and method for Electronic 
Transaction Systems, and, more specifically, for using XML to build real-time 
electronic financial transaction interfaces, in a language other than XML, that 
process the Financial Service Transactions. 

BACKGROUND OF THE INVENTION 

Many different computer systems exist today which request and receive 
electronic financial data. Computer systems that contain large amounts of data, 
referred to herein as "host systems," comprise large legacy systems and smaller 
scaled information servers. Host systems store information for a plurality of 
financial accounts, including checking accounts, credit accounts, money market 
accounts, and other kinds of financial market accounts. A plurality of different 
computer systems ("client systems") access the information stored on host 
systems and include personal computers, automatic teller machines, point-of-sale 
terminals, teller terminals, and any other consumer to business ("C2B"), business 
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to business ("B2B") or business to business to consumer ("B2B2C"). Host 
systems and client systems interface with each other using middleware 
application software. Middleware applications route messages to and from 
designated endpoints (i.e., computer systems) over communication networks, 
5 such as the Internet. The financial industry constantly pressures financial 
institutions to deliver new, improved and uninterrupted supplies of financial 
information services. Middleware applications assist by connecting multiple 
client systems with multiple core processing systems (i.e., host systems) for 
services such as Electronic Financial Transactions ("EFT's"). Middleware 
|fj 10 applications provide "real-time" connectivity, in addition to managing multiple 

W. channels, by routing message transactions to appropriate destinations. Moreover, 

Jj middleware applications provide mechanisms to handle error conditions to ensure 

SO that customer accounts are not adversely impacted by communication and data 

|| errors. Middleware applications also provide detail logs which provide a record 



15 of each message transaction 

m . 



A client system communicates with a host system via an application 
program interface ("API"). An API includes a set of definitions that enable 
programmers to use one or more features of the corresponding program 
application. A host system's API can incorporate some well recognized formats, 
20 such as the Open Financial Exchange ("OFX") or International Standards 

Organization ("ISO") formats. Alternatively, API's can incorporate proprietary 
formats, or some combination of both well-known and proprietary formats. 

In order for a client system and a host system to communicate, 
programmers must adhere to the rules associated with each API. Technical 
25 specifications that are directed to a host system's API are provided in the industry 
to enable programmers to properly format message requests and responses. A 
computer program, referred to herein as a "message interface," enables the 
disparate systems to understand each other. The message interface operates to 
format data requests and responses, for example between financial computer 
30 systems, so the receiving system can interpret the data. 
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In the prior art, developing new message interfaces between banking 
systems typically requires gathering a team of people comprising at least one high 
level programmer and a technical documenter. The technical documenter 
develops a "mapping document" that explains the API for one or more 
programmers, and the programmer(s) develop computer program source code for 
message interfaces in response thereto. 

The prior art development process for message interfaces is typically 
fraught with errors. For example, programmer(s) misinterpret a technical 
documenter's mapping document. Moreover, program "bugs" (e.g., program 
loop errors and memory management errors) cause errors during "run time" 
operations. The development and deployment time required for message 
interfaces can, therefore, be significant and costly due to errors and/or program 
bugs. 

Fig. 1 shows two example data streams 2 that are transmitted between host 
systems and client systems. One data stream 2 is directed to a data packet for 
requests, the other data stream 2 is directed to a data packet for responses. 

Fig. 2 shows a corresponding API specification 4 that is used to access and 
manipulate the data in the data stream 2. The API specification 4 identifies the 
fields in the data stream, and further provides descriptions of the fields enabling 
the programmer(s) to develop message interfaces. The example API specification 
4 shown in Fig. 2 includes default values, data formatting rules and record 
definitions for request data packet 6, and response data packet 8. 

Fig. 3 shows an example of a prior art mapping document 9. The 
document is developed by a technical person, and describes the specifications 
required to develop a message interface to effectuate communication between a 
client system and a host system. 

Fig. 4 shows a flowchart illustrating a typical prior art process for building 
message interfaces. In step S10, a technical specification of a host API is 
received. In step S12, a technical documenter (e.g., a project manager) develops 
a mapping document to be used by programming staff to develop source code for 
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a message interface. In step S14, programmer(s) generate and/or debug the 
program source code for the message interface. In step SI 6, the programmer(s) 
compile the source code into machine readable object code. In step SI 8, a 
determination is made by the programmer(s) whether or not the source code 
contains errors. For example, the source code may not compile, or compile with 
errors, and require changes thereto. When errors are discovered, the process 
loops back to step SI 4, the programmer(s) debug the source code, and compile 
the source code again in step SI 6. When the programmer(s) eventually compile 
the source code without errors, the process moves to step S20, and the message 
interface is deployed. The interface may still contain errors, for example due to 
misinterpretation of the technical documenter's mapping document. In step S22, 
if errors are found, the process loops back to step S14, and the programmers) 
debug the source code to identify and repair errors therein. The process continues 
indefinitely until the application runs free of errors, which, potentially, can take 
months to complete. 

SUMMARY OF THE INVENTION 

There is a need for a system and method to build message interfaces 
quickly and accurately without having to rely on technical documenters and 
computer programmers. New host systems and client systems continually emerge 
and require new API specifications and message interfaces to be developed. In 
the prior art, development of message interfaces, for example, to facilitate 
communication between disparate banking systems, is hampered by errors caused 
by misinterpretation and program bugs. 

The present invention provides an efficient system and method for 
building message interfaces by eliminating steps required in the prior art. The 
present invention provides significant time and resource savings because, as 
described in detail below, fewer parties are involved in the message interface 
development process. Moreover, production of accurate program code that 
operates free of typical development and run-time errors, for example, compiling 
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errors, infinite loops and memory management problems, is ensured. The present 
invention effectively automates processes that, in the prior art, had to be 
performed by specialized personnel. Therefore, the need for programmers and 
technical writers to generate message interfaces is effectively eliminated by the 
present invention. 

In a typical arrangement, one message interface is developed for a host 
system and another interface is developed for a client system. Both message 
interfaces interact with middleware applications. Middleware applications route 
messages between multiple host systems and multiple client systems, for example 
in the banking industry. In accordance with the principles of the present 
invention, one party develops the message interfaces, thus eliminating the need 
for a documenter and a software developer (i.e., a programmer). Moreover, the 
resulting message interface modules are accurate and plug into the middleware 
application software seamlessly. 

The present invention preferably provides a middleware schema for 
describing message transactions. A structured framework of commands and 
attributes is employed by technical personnel to develop messages that comply 
with a target host API, such as the Electronic Funds Transfer networks and other 
core processing systems. The middleware schema preferably directs the 
development of a message interface document. By adhering to the schema, high 
level program source code is generated that operates on data messages ensuring 
compliance with a target API. 

Examples of functionality provided by the present invention include: 
defining bit positions and setting a bit map; creating packed or unpacked bit 
maps; creating packed or unpacked data fields; defining byte positions and setting 
a byte map; formatting fields (left or right justification); adding length indicators; 
padding fields with leading or trailing characters; and translating and formatting 
fields from an internal field structure to an external field structure. 

The middleware schema, in accordance with the principles of the present 
invention, allows a technical person, for example a project manager, to use 
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English-like words to develop message interface documents. Knowledge of a 
particular programming language is not required of the technical person. Once he 
or she is familiar with the target API and the middleware schema, the technical 
person preferably uses a "front-end" software application to develop a source 
document via the middleware schema. The present invention uses the source 
document to generate a complex and customized message interface in a high level 
programming language quickly and accurately. 

In the preferred embodiment, the middleware schema is constructed in the 
extensible markup language ("XML"), a relatively easy pseudo-program 
development language. XML is preferred because it is flexible and relative easy 
to use. In accordance with the principles of the present invention, any language, 
even a spoken language (e.g., English) can be used in lieu of XML. 

When complete, the source document developed by the technical person is 
generated into high level program source code, for example, VISUAL BASIC, 
VISUAL C++, or Java. The source code is then compiled into machine-readable 
object code, for example, into a dynamic link library ("DLL") file, and 
seamlessly plugged into a middleware application. Notwithstanding a lack of 
knowledge of a specific Component Object Model (COM) architecture or a 
specific object-oriented programming language, users of the present invention 
build and customize message interfaces quickly and accurately that comply with 
variations on API protocols, for example, the International Standards 
Organization 8583 interface. 

The present invention preferably does not use translation tables to generate 
message interfaces. Instead, documents created with the convenient front-end 
application are evaluated by the present invention and generated into high-level 
computer program source code. The source code is assured compliance with a 
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target API because the middleware schema defined by the present invention is 
recognized during the process of generating the source code. 

By allowing for source documents to be generated into source code by 
project managers without the need for programmers, new message interfaces are 
created in a fraction of the time needed in prior art development environments. 
Significant expenses associated with developing message interfaces are, 
therefore, eliminated. Moreover, accuracy is assured because the front-end 
application ensures adherence to the middleware schema, thus generating bug- 
free source code. 

In summary, in accordance with the principle of the present invention, a 
project manager or other technical person (not necessarily a programmer) 
develops a source document using the front-end application, and generates the 
source document into high-level computer program source code. The project 
manager further compiles the source code into a machine readable interface, 
designed to plug into a middleware application. As noted above, middleware 
applications, such as VT SERVER, route messages between host systems and 
client systems, and are known in the art. 

BRIEF DESCRIPTION OF THE DRAWING(S) 

For the purposes of illustrating the invention, there is shown in the 
drawings a form which is presently preferred, it being understood however, that 
the invention is not limited to the precise arrangements and instrumentality 
shown. The features and advantages of the present invention will become 
apparent from the following description of the invention that refers to the 
accompanying drawings, in which: 

Fig. 1 illustrates a data stream packet transmitted between host systems 
and client systems; 
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Fig. 2 illustrates an example API specification; 

Fig. 3 is an example prior art mapping document for programmers to 
develop message interfaces for an API; 

Fig. 4 shows a flowchart illustrating the prior art steps for generating an 
interface; 

Fig. 5 shows an example hardware arrangement for a network based 
system according to the principles of the present invention; 

Fig. 6 is a block diagram of the functional elements constructed in 
accordance with the present invention; 

Fig. 7 is a flowchart illustrating the steps for generating an interface 
according to the principles of the present invention; 

Fig. 8 shows a detailed flowchart illustrating the steps for generating a 
source document into a source code written in a high level programming 
language; 

Fig. 9 illustrates a sample program code to handle outgoing messages; 
Fig. 10 illustrates sample programming code to handle incoming 
messages; and 

Fig. 1 1 illustrates a sample front-end application for developing source 
documents. 

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION 

The present invention provides for an improved way to create message 
interfaces for client systems to communicate with host systems. In accordance 
with the principles of the present invention, a technical person (e.g., a project 
manager) develops a source document by employing a predefined middleware 
schema. Using the present invention, the technical person generates the source 
document into source code that is in a high level programming language, for 
example, VISUAL BASIC, and the module that is produced therefrom is 
compiled and deployed. 

Referring to the drawings in which like reference designators refer to like 
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elements there is shown in Fig. 5 an example of a first preferred embodiment 
including a hardware arrangement for developing message interfaces and referred 
to generally as Message Interface System 10. Message Interface System 10 
comprises at least one host system 12 and at least one client system 14, each of 
5 which are coupled to communication network 16. Host system 12 preferably 
includes all databases necessary to support the present invention. However, it is 
contemplated that host system 12 can access any required databases via 
communication network 16 or any other communication network to which host 
§ system 12 may be coupled. Communication network 16 is preferably a global 

10 public communication network such as the Internet, but can also be a wide area 

H .. § 

network (WAN), local area network (LAN), or other network that enables two or 
%j more computers to communicate with each other. 

In the preferred embodiment, host system 12 and client system 14 are any 
£3 devices that are capable of sending and receiving data across communication 

III 15 network 16, e.g., mainframe computers, mini computers, personal computers, 

fy laptop computers, personal digital assistants (PDA) and Internet access devices 

|y such as Web TV. In addition, client systems 14 are preferably equipped with a 

web browser, such as MICROSOFT INTERNET EXPLORER, NETSCAPE 

NAVIGATOR and the like. Host systems 12 and terminals 14 are coupled to 
20 communication network 1 6 using any known data communication networking 

technology. 

As shown in Figures 5 and 6, the functional elements of each host system 
12 include one or more central processing units (CPU) 18 used to execute 
software code and control the operation of host system 12, read-only memory 

25 (ROM) 20, random access memory (RAM) 22, one or more network interfaces 24 
to transmit and receive data to and from other computing devices across a 
communication network, storage devices 26 such as a hard disk drive, floppy disk 
drive, tape drive, CD ROM or DVD for storing program code, databases and 
application data, one or more input devices 28 such as a keyboard, mouse, track 

30 ball, microphone and the like, and a display 30. 
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The various components of host system 12 need not be physically 
contained within the same chassis or even located in a single location. For 
example, storage device 26 may be located at a site which is remote from the 
remaining elements of host systems 12, and may even be connected to CPU 18 
5 across communication network 16 via network interface 24. Host systems 12 
include a memory equipped with sufficient storage to provide the necessary 
databases, forums, and other community services as well as acting as a web server 
y, for communicating hypertext markup language (HTML), Java applets, Active-X 

g control programs and the like to client systems 14. Host systems 12 are arranged 

If i o with components, for example, those shown in Fig. 5, suitable for the expected 

K operating environment of host system 12. The CPU(s) 18, network interface(s) 

%J 24 and memory and storage devices are selected to ensure that capacities are 

arranged to accommodate expected demand, 
p. As used herein, the term "link" refers to a selectable connection from one 

pi 1 5 or more words, pictures or other information objects to others in which the 

U selectable connection is presented within the web browser. The information 

| object can include sound and/or motion video. Selection is typically made by 

"clicking" on the link using an input device such as a mouse, track ball, touch 
screen and the like. Of course, one of ordinary skill in the art will appreciate that 
20 any method by which an object presented on the screen can be selected is 
sufficient. 

The functional elements shown in Fig. 6 (designated by reference 
numerals 18-30) are the same categories of functional elements present in client 
systems 14. However, not all elements need be present, for example, storage 
25 devices in the case of PDA's and the capacities of the various elements are 
arranged to accommodate the expected user demand. For example, CPU 18 in 
client system 14 may be a smaller capacity CPU than the CPU present in the host 
system 12. Similarly, it is likely that the host system 12 will include storage 
devices of a much higher capacity than storage devices present in client system 
30 14. 



pi 
S3 
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Of course, one of ordinary skill in the art will understand that the 
capabilities of the functional elements can be adjusted as needed. The nature of 
the invention is such that one skilled in the art of writing computer executable 
code (i.e., software) can implement the described functions using one or more of 
5 a combination of popular computer programming languages and developing 
environments including, but not limited to C++, Visual Basic, Java, HTML and 
web application development applications. 

Although the present invention is described by way of example herein and 
in terms of a web-based system using web browsers and a web site server (host 
10 system 12), Message Interface SystemlO is not limited to the above 

N configuration. It is contemplated that Message Interface SystemlO is arranged 

H 

SJi such that client systems 14 communicate with and display data received from host 

systems 12, using any known communication and display method, for example, 
P using a non-Internet browser WINDOWS viewer coupled with a local area 

1 5 network protocol such as the Internet Packet Exchange (IPX), dial-up, third-party, 
private network or a value added network (VAN). 
|jj It is further contemplated that any suitable operating system can be used 

on client system 14, for example, DOS, WINDOWS 3.x, WINDOWS 95, 
WINDOWS 98, WINDOWS NT, WINDOWS 2000, WINDOWS ME, 
20 WINDOWS CE, WINDOWS XP, MAC OS, UNIX, LINUX, PALM OS and any 
other suitable operating system. 

As used herein, references to displaying data on client system 14 refers to 
the process of communicating data to the terminal across communication network 
16 and processing the data such that the data is viewed on the terminal displays 
25 30, for example by using a web browser and the like. As is common with web 
browsing software, the display screen on terminals 14 present sites within the 
networked system 10 such that a user can proceed from site to site within the 
system by selecting a desired link. 

Further, references to displaying data on client system 14 regard the 
30 process of communicating data to the terminal across communication network 16 



m 
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and processing the data such that the data can be viewed on the client systems' 
displays 30 using web browsers and the like. The display screens on client 
systems 14 present areas within Message Interface SystemlO such that a user can 
proceed from area to area within the System by selecting a desired link. 
Therefore, each user's experience with Message Interface SystemlO is based on 
the order with which they progress through the display screens. Graphic controls 
are available in the display screens and modules to initiate data processes, and to 
provide convenient navigation between the display screens and modules of 
Message Interface Systeml 0. In other words, because the system is not 
completely hierarchical in its arrangement of display screens, users can proceed 
from area to area without the need to "backtrack" through a series of display 
screens. For that reason, and unless stated otherwise, the following discussion is 
not intended to represent any sequential operation steps, but rather to illustrate the 
components of Message Interface SystemlO. 

As noted above, the client system and host system typically communicate 
through middleware application software. The messages transmitted are typically 
in a specific "native" format. A middleware application routes the messages to 
their proper end-points, thereby connecting multiple delivery channels with 
multiple core processing systems. Message interfaces are necessary to format 
data messages in recognizable ways to ensure client systems and host systems can 
communicate. 

In accordance with the principles of the present invention, an API 
specification defines how data are to be formatted so that data requests and 
responses will comply with API specifications. The sample API specification 4 
(Fig. 2) defines, among other things, a record layout for a host system API. 

In the API specification 4, two kinds of data packets are identified: request 
data packet 6 and response data packet 8. Request data packet 6 is directed to a 
request for data stored on a host system, and is transmitted from a client system. 
Response data packet 8 is directed to data sent from a host system that replies to a 
client system's data request. 
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In the example shown in Fig. 2, request data packet 6 identifies six fields: 
a transaction code, a credit union access code, a member number, an account 
suffix, a transfer amount and a post indicator. Each field in the API specification 
4 has a specific format, for example a field type and field length and default 
5 entry. For example the transaction code has is an numeric field, is 3 digits long 
and has a default value of "033." 

Similar to the request data packet 6, the response data packet 8 comprises 
a plurality of fields including transaction code, credit union access code, member 
jW number and host response code. Additionally, default data values and data 

Jfi 10 formats are provided. As shown in the example request data packet 6, the 

transaction code for the response data packet 8 is a three digit numeric value. 
Also, the transaction code in the response data packet 8 has a default data value of 
"033." 

As described above with regard to the prior art process of developing 
15 message interfaces between client systems and host systems, the API 

specification 4 provides details of the specific API's used by client and host 
§j systems. When an interface is developed and complies with the API 

specification, the middleware application software delivers intelligible messages 
between the host and client systems. 
20 Now referring to Fig. 7, the process of generating message interfaces 

according to the present invention is illustrated. The present invention effectively 
eliminates the need for a technical person to develop a mapping document 
describing a target API for a programming team to use as guidelines. Moreover, 
the present invention eliminates the need for one or more programmers to 
25 implement the mapping document into high-level program source code. Instead, 
as noted above, a project manager or other technical person develops a source 
document that is generated into a high-level computer program language, for 
example VISUAL C++ or VISUAL BASIC. In accordance with the principles of 
the present invention, the computer program source code is compiled into 
30 machine readable object code, thus producing an interface and enabling 
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communication between a client system and a host system. 

In step SI 00 (Fig. 7), a technical specification of the host system API is 
received from the host system. In step SI 02, a technical person (e.g., a project 
manager) develops and/or debugs a source document to be generated into high 
5 level program source code in accordance with the principles of the present 
invention. In the preferred embodiment the source document is generated in 
XML. In step SI 04 the technical person processes the source document and 
generates source code therefor. During the step of generating the source 
document into program source code, errors may be discovered, thus identifying 
10 problems with the source document. Example source document errors include 
logic problems, syntax errors, or non-compliance with the middleware schema. 
H In the event that errors are found, the technical person developing the source 

document is prompted to correct the source document (step SI 06). When the 
P error(s) are discovered, the process reverts back to step SI 02. The technical 

gjj 15 person makes the corrections to the source document and again generates the 

f W source document in to program source code. When all errors are remedied, 

fy program source code is generated in a desired, high level programming language, 

for example VISUAL C++ or Java,. Thereafter the application is compiled into 
machine readable object code (step SI 08), distributed and deployed (step SI 10). 
20 Fig. 8 shows more detail regarding step SI 04, i.e., the step of processing 

the source document. In step SI 12, the source document created by the technical 
person is loaded into memory. In step SI 14, recognizable nodes (i.e., functional 
blocks of the source document) are searched in the document file for processing. 
The nodes to be processed contain recognizable keywords that are available via 
25 the middleware schema. When recognized nodes are identified, a series of 

conditional statements are evaluated by the present invention. For example, if a 
node has an attribute that is considered TRUE, the code generating part of the 
invention spawns source code directed to the functionality contained therein. 
In the example shown in Fig. 8, the present invention searches for the 
30 node tag, "LogMessageln," in the source document (step SI 14). If a 
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LogMessageln node is found by Message Interface System 10 (step SI 15), then 
the system loops to step SI 16 and a variable, "X" is set to equal the number of 
LogMessageln nodes contained in the file. Moreover, a counter variable, "Y", is 
set to equal 1 and acts as an index for a program loop. If a LogMessageln node is 
5 not found, the process terminates (step S140). 

In step SI 18, Message Interface System 10 locates Y* h occurrence of the 
LogMessageln node. For example, where Y equals 1, the first occurrence of the 
LogMessageln node is located by Message Interface System 10. 

Once a node is recognized, in the present example the LogMessageln 
10 node, Message Interface System 10 preferably evaluates the node and identifies 
pj specific functionality therein. The system generates corresponding source code 

>1 based upon the attributes associated with the evaluated node. The source code is 

P 

B r temporarily stored in memory while the system searches for child nodes of the 

P parent node, LogMessageln node number 1 (step SI 22). 

gj 1 5 Similar to processing parent nodes, Message Interface System 1 0 sets a 

f j variable, "W," to equal the number of child nodes of the parent node number Y. 

Hi Also, the system will set a counter variable, V, to equal 1 (step S124). Thereafter, 

the system will locate the V th occurrence of the child node of the parent node Y. 
For example, where V equals 1 , the first child node of the parent node, 
20 LogMessageln number 1, is located (step SI 26). 

In step S 128, Message Interface System 1 0 processes child node number 
V of node LogMessageln number Y. The system evaluates the contents of child 
node V and generates source code corresponding with the attributes of the child 
node being examined. When the system is finished processing the child node, it 
25 proceeds to step SI 30 where it increments the counter variable, V, by 1. 

Continuing with the current example, V now equals 2 and Message 
Interface System 10, in step S132, evaluates whether the value of V is greater 
than the value of W (i.e., whether there are any remaining unprocessed child 
nodes of the parent node). In the event that V is less than or equal to W, then the 
30 system loops back to step S126 and locates the next child node of the parent node, 
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LogMessageln node number 1. The system proceeds to step SI 28 and evaluates 
the child node number 2 and when completed, proceeds back to step SI 30 where 
the counter, V, is again incremented by 1 . 

In step S132, the system evaluates whether V is greater than W (i.e., 
whether there are no child nodes left to process) and, if the system has processed 
all of the corresponding child nodes, the system loops to step SI 34 and 
increments the counter Y. The counter Y represents the next parent node, in this 
example the next LogMessageln node to evaluate. The system then determines, 
in step S136, whether the value of Y is greater than the value of X (i.e., whether 
there are any parent nodes left to process). In the event that Y is less than or 
equal to X ? Message Interface System 10 loops back to step SI 18 and locates the 
next, unexamined, LogMessageln node. The process continues until Y is greater 
than X, and there are no LogMessageln nodes left to process. 

Continuing with the current example, after all of the LogMessageln nodes 
are evaluated, the system proceeds to step SI 38 and source code is generated and 
appended to a file. In an alternative embodiment, Message Interface System 10 
appends program source code generated during the evaluation process 
immediately to an existing file. After the source code is generated, then the 
system loops back to step SI 14 to locate the next recognized node, for example, 
"LogMessageOut." The process repeats until all parent nodes in the source 
document have been processed. 

Figure 9 contains program code which illustrates how a source document 
is evaluated. As shown in lines 1-3, the individual node, "LogMessageln" is 
located, and the number of LogMessageln node occurrences is determined at lines 
5-8. The system loops through each LogMessageln parent node to process the 
contents therein, as shown in line 10. For each LogMessageln node, Message 
Interface System 10 appends source code in the target programming language. In 
the example shown in lines 19-32, program code is generated in the VISUAL 
BASIC programming language, and in an alternative embodiment, lines 35-50 
depict programming code being generated in the C++ programming language is 
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shown. 

Fig. 10 shows a sample of program code directed to processing individual 
message nodes according to the principles of the present invention. Lines 4-9 
therein illustrate how child nodes of a parent node are identified and counted. As 
with the parent nodes, the system loops through each child node for processing. 
Beginning at line 56, the child node, "IDTAGJ3itmapDateIn" is identified and 
the attributes thereof are evaluated. Message Interface System 10 evaluates the 
extracted data and, provided no errors are found, program source code is 
generated in the target programming language. The source code is appended to a 
file, as shown in line 74. As noted above with respect to step SI 32 (Fig. 8), the 
process of extracting child nodes repeats until all of the child nodes have been 
evaluated and/or generated into target source code. 

After the source code is generated, Message Interface System 10 
preferably automatically launches the corresponding program development 
environment of the target source code programming language, e.g., VISUAL 
BASIC or VISUAL C++. When the development environment is active, the 
technical user compiles the generated source code into object code using the 
functionality provided therein. In other words, using the "native" interface, the 
user compiles the source code generated by Message Interface System 10. 

The logic associated with parent nodes, also known in the industry as "top 
level nodes," typically relates to broad data management activity. For example, 
in an XML document, MessageOut nodes handle the broad concept of delivering 
messages to a host system. Other examples of top level nodes in XML include 
"InterceptMessage" nodes for handling unsolicited messages sent from a host 
system, "Messageln" nodes for handling incoming messages from a host system, 
"LogMessageln" and "LogMessageOut" nodes for handling logging the messages 
sent via Messageln and MessageOut nodes. Log messages provide English-like 
messages to a user in order to identify a specific occurrence of activity. Within 
the top level nodes, more specific formatting instructions and other data related 
instructions are provided by corresponding child level (or "lower level nodes"). 
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The processes employed by the present invention to evaluate parent nodes 
and child nodes is essentially identical, with one exception being the nature of the 
conditional being employed. For example, the MessageOut node instructs output 
to be sent to the host system device through the middleware application software. 
5 Child nodes related to the MessageOut node direct the formatting of the data that 
are sent to the host system. 

During the evaluation of the source document, a stringent check of syntax 
is performed to ensure that all of the nodes are defined and formatted correctly. 

S3 If a document is not "well formed," then either the node will not be evaluated 

13 

p| 10 properly, or the source code that is generated in response thereto will not function 

™ correctly. The ability of Message Interface System 10 to ensure that the source 

document is well formed assures accurate and functional source code that will 
interface with middleware applications seamlessly. By ensuring the accuracy of 
the generated source code during the development of the source document, 
pi 15 resources, including time and money, are saved. If any information is missing 

from a node, or the document is not well formed for other reasons, an error 
message is preferably generated to alert the author of the source document that an 
error exists and requires correction. 

In a typical host to client messaging system, one module is used to handle 
20 messages being sent from a host system, and a separate module is used to handle 
messages being sent from a client system. Typically, a plurality of modules are 
created for handling messages sent a plurality of host systems because the host 
systems each have unique API's. However, a single client system module can be 
designed which handles messaging with a plurality of host systems, and to receive 
25 a plurality of messages sent from a plurality of host systems. For example, a 

client system transmits a request to a host system in a specific format. The client 
system further expects that the response from the host system will be formatted 
according to the client's API. Therefore, regardless of the host system that 
transmits requests or responses to a client, the client system expects the message 
30 to be formatted in a single, specific way. One single module, therefore, handles 
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formatting messages that are received from a plurality of host systems. 
Whenever a client system communicates with a new host system, however, a new 
message interface must be developed to accommodate the host systems API 

To further expedite the message interface building, Message Interface 
System 10 provides a convenient graphic user interface to develop new message 
interfaces. A discussion regarding the graphic user interface to develop new 
message interfaces is now provided. 

The front-end user application provided by Message Interface System 10 

enables a technical person, for example a project manager, to develop source code 
efficiently. In the example shown in Fig. 1 1, a user generates source code by 
developing an XML document via the front-end application 3 1 , As shown in Fig. 
11, commands that are compatible with the middleware schema are provided in 
command window 32. The technical person uses a pointing device, such as a 
mouse or trackball, to select a command in the command window 32, and further 
to assign attributes to the command in order to identify formats and values 
therefor. In the variable window 34, as shown in Fig. 1 1, the technical person can 
review the status of specific variables and status of the source document being 
generated. In the source document window 36, the source document is displayed. 
In command help window 38, the technical person is provided with information 
regarding the specific command being used. Additionally, users are prompted to 
comply with the middleware schema, as shown in prompt window 40. Moreover, 
windows 32-40 are capable of displaying information besides commands, status 
information, source document information, help and prompts. 

According to the principles of the present invention, the contents of any of 
the windows in the front-end application can change dynamically. Depending 
upon the context, the windows 32-40 display varying information. For example, 
help window 38 can display information regarding the overall formation of the 
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source document. If errors are found in the source document, the nature of the 
errors and suggested fixes are shown in help window 38, After the technical 
person is satisfied with the source document, he or she selects a graphic control in 
the display screen to generate source code in the target programming language. 
For example, the user selects a graphic icon which instructs the application to 
generate source code, and the user selects C++ from a list of available 
programming languages. During the source code generation process (described 
above with reference to Fig. 7), if any errors are found then Message Interface 
System 10 preferably prompts the user thereto. The technical person is then able 
to make necessary corrections to the source document and the generation of 
source code process begins again. 

By using the front-end application to develop source documents, 
eventually source code, Message Interface System 10 provides a unique and 
efficient way to generate source code for message interfaces. Rather than hand 
typing a source document that is compliant with a middleware schema, a user of 
the present invention has a series of prompts and controls to generate the source 
document. As noted above, the technical person is assured that the source 
document is well formed, and that the source code that is generated therefrom 
will run correctly. 

Although the present invention has been described in relation to particular 
embodiments thereof, many other variations and modifications and other uses 
will become apparent to those skilled in the art. Therefore, the present invention 
should be limited not by the specific disclosure herein, but only by the appended 
claims. 
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